The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Database systems typically store database objects (e.g. tables, indexes, etc.) on disk, and load data items from those database objects into volatile memory on an as-needed basis. Once loaded into volatile memory, the data items may remain cached in volatile memory so that subsequent accesses to the same data items will not incur the overhead of accessing a disk. Those data items may be replaced in cache, for example, to make room in volatile memory to store other data items that have been requested.
Rather than load individual data items on a per-item basis, entire database objects, or portions thereof, may be pre-loaded into volatile memory. Various approaches for loading entire database objects, or selected portions thereof, into volatile memory to speed up database operation processing are described in U.S. patent application Ser. No. 14/377,179, entitled “Mirroring, In Memory, Data From Disk To Improve Database operation Performance”, filed Jul. 21, 2014, referred to herein as the “Mirroring” application, the contents of which is incorporated herein in its entirety.
According to the approaches described in the Mirroring application, database objects, or portions thereof, are stored in volatile memory in a different format than the format that those same objects have on disk. For example, the in-memory copies of the objects may be stored in a column-major format, while the on-disk copies are stored in a row-major format. An in-memory version or copy of an object (or selected portions thereof), is referred to herein as an In-Memory-Columnar Unit (IMCU).
On-disk data is stored in “blocks”. For disk blocks that store data for a table of a database, a single block may contain items from a plurality of rows of the table. When a particular node wishes to make a change to one or more items that are stored in a particular block, the particular node obtains a write lock that covers the particular block, loads a copy of the block into a buffer cache in volatile memory, and makes the change to the cached copy of the block. When the transaction that made the change commits, the changes made by the transaction become permanent.
When the data items in a block are changed, then the copies of those data items that reside in IMCUs become stale. For example, assume that block A has items X, Y and Z, and that a transaction in node 1 updates item X. Assume further that copies of items X, Y and Z are in an IMCU in node 2. After the update to item X made in node 1, the copy of item X in the IMCU in node 2 is stale. To prevent the use of stale data, node 2 responds to the update to block A by updating locally-stored invalidity data to indicate that, within its IMCU, block A is invalid.
When the invalidity data for an IMCU indicates that a block is invalid, then the node that hosts the IMCU must go to a source other than the IMCU to obtain the current version of data from the block. For example, because node 2 has marked block A as invalid for its IMCU, node 2 will respond to requests for current versions of items X, Y and Z by obtaining those versions from other sources (such as an in-memory journal, buffer cache, or disk). Because these items must be obtained from other sources, the efficiency improvement that results from maintaining the IMCU in node 2 is diminished.
In the foregoing example, only item X was actually updated. Consequently, the IMCU within node 2 actually has the most recent version of items Y and Z. However, because the invalidation is performed at the block level, node 2 treats all items from block A as being invalid. Thus, node 2 looks elsewhere for the current versions of items Y and Z even though the IMCU within node 2 has the current versions of items Y and Z.